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SECTION I 
INTRODUCTION 


1-1. NEED FOR DEBUGGING DEVELOPMENT 


Debugging is a general term that refers to the loca- 
tion and correction of errors that occur in computer pro- 
grams. The debugging activity may consume considerable 
portions of the total time required for the complete pro- 
gram development. However, the importance of this area of 
program development has often been minimized. The purpose 
of this report is to place some emphasis on this important 
area and to present some of the current debugging concepts 
which may be considered for implementation. 

Computers are continually becoming faster and more 
complex, and applications becoming more extensive, more 
intricate, and more time-critical. Thus, the need for a 
greater effort in the area of debugging is obvious. Two 
of the major factors which make program errors both harder 
to find and harder to tolerate are time -cons trained program- 
ming and closed-loop applications. These are particularly 
applicable to many of the space-related programs. 


1-2. SCOPE OF THIS REPORT 


The project that has furnished impetus to this 
report is the IMP-F (Interplanetary Monitoring Platform) . 
Because the IMP-F computer program complex will form the 
basis for future IMP efforts, it was necessary to document 
the present version as fully as possible in order to reduce 
the lead time and cost of developing the follow-on IMP 
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complexes. One important area (and the subject of this 
paper) is debugging. This report includes, in addition 
to the documentation of the IMP-F debugging effort, a 
survey of current debugging concepts which may be considered 
for implementation in future programs. 


1-3. DEBUGGING ASPECTS, DEFINITIONS 

For the purposes of this report, debugging will be 
considered to include logical and clerical errors but not 
machine malfunctions. To be more specific, debugging 
includes prevention, detection, diagnosis, recovery, and 
remedy of program errors. It is an on-going process that 
lasts for the entire lifetime of the program. The following 
definitions clarify the above mentioned aspects 

a. Prevention - protective action taken against 
the occurrence of errors or omissions. 

b. Detection - determination of the occurrence 
of an error or of an omission at the earliest 
point possible so as to limit the consequences. 

c. Diagnosis - analysis of the error that was 
detected. 

d. Recovery - provision for a means of bypassing 
an error condition, especially one of an 
intermittent nature, with a minimum loss of 
time and effort. 
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e. Remedy - rapid remedial action employed to 
prevent further occurrences of the same or 
similar errors and omissions. 


1-4. CATEGORIES OF PROGRAMMING ERRORS 


Programming errors fall into two basic categories - 
logical and clerical. 

Logical errors are those which involve problem 
analysis. Although they occur less frequently than clerical 
errors they are usually more serious and more difficult to 
detect. Since they often occur early in the program writing 
process, they have a tendency to be overlooked. Frequently 
they are a result of a misunderstanding of the problem and 
requirements. Often, in very complex programs, errors result 
from failure to cover all possible alternatives that may 
arise, from improper identification of storage areas, etc. 

Clerical errors are those errors which involve the 
input deck or other input media; these errors are sometimes 
referred to as physical errors, and errors made in writing 
symbolic instructions. Numbers may be transposed, cards 
may be omitted or mispunched, a symbolic name may be 
spelled more than one way, to mention a few types of these 
errors. Frequently these errors are the result of careless- 
ness. One common source of such errors may be avoided by 
keeping program listings and decks up to date; old versions 
should be destroyed or at least marked. 
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1-5. 


PHASES OF DEBUGGING 


The debugging process is generally thought of as 

? 

consisting of several phases: 

a. Desk checking. 

b. Assembled or compiled program checking. 

c. Program-testing using test data. 

d. Error diagnostic procedures. 

e. Running of program using actual data. 


1-6. ERROR DIAGNOSTIC PROCEDURES 


In this report, emphasis is placed on the phase 
dealing with error diagnostic procedures. A number of 
programs and programming techniques are available for 
diagnostic purposes. Their underlying principle is to 
provide information about a particular portion or portions 
of the program as control passes through the specified 
instructions. The amount and location of the information 
will vary depending on the nature of the error. Proposals 
have been made for developing software that will allow 
debugging to be conducted using the same language as the 
source program; however, few of these have been implemented. 
Few if any computer systems or major languages today. pro- 
vide comprehensive symbolic debugging software packages. 
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SECTION II 

IMP-F PROGRAM DEBUGGING 


2-1. DESCRIPTION OF THE PROGRAMS 


Information concerning the debugging of time- 
correction and decommutation programs for the IMP-F space- 
craft was collected through a series of interviews with 
programmers and project managers associated with the pro- 
ject. 


The IMP-F time-correction and decommutation programs 
were lirritten in FORTRAN and the UNIVAC 1108 assembler langu- 
age, SLEUTH II. 

a. The time -correction programs perform two basic 
operations : 

1. Correct range time data by removing 
discontinuities and filling in missing 
time data. 

2. Establish fairly precise correlation of 
spacecraft events with range (earth-based) 
time signals by correcting for propaga- 
tion delay. 

b. Decommutation operations are concerned with 
stripping out, formatting, and providing 
pertinent data for each experimenter. 
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2 - 2 . 


PROGRAMMER COMMENTS 


In general, the programmers associated with the 
project felt the diagnostic system that was available within 
the 1108 Executive system was adequate for their debugging 
needs. The 1108 diagnostic system provided for snapshot 
and postmortem dumps. However, some comments and sugges- 
tions were made that may provide some insight into debug- 
ging procedures that may be considered for implementation 
in future IMP programs. Among these suggestions were the 
following : 

a. Debugging aids may be too expensive and involve 
excessive overhead. They may require excessive 
core storage and increase running time beyond 
practical limits. 

b. Care should be taken when implementing debugging 
aids not to duplicate aids that are already 
provided for by the manufacturer's system. 

c. During the writing of the IMP-F programs, a 
change in personnel occurred. The programmers 
that took over the project felt a trace routine 
would have been desirable, but that the imple- 
mentation of a built-in trace routine should 
have been accomplished during the design phase, 
since a great deal of work is entailed when 
such a routine is implemented during later 
phases . 

d. The WOLF programmers assigned to the IMP-F 
project were able to use snapshot dumps for 
their tracing needs. However, a problem 
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associated with the postmortem dump was that 
whenever the system was lost through a drum 
failure, illegal instruction, system failure, 
etc., then the dump was also lost. 

e. Imbedded comments were not only useful for 
debugging purposes but were valuable in 
estimating running time. 

f. Two specific suggestions were made concerning 
future IMP programs : 

1. The first was to develop routines that 
would check experimenter's tape for known 
characteristics such as label, format, 
size, and special characters, and 
especially data. 

2. The second was to develop a better method 
of obtaining test data. 

2-3. INTERVIEW GUIDELINES 


The following is a copy of the checklist of subjects 
in conducting the interviews with the IMP-F programmers and 
project managers. 


CHECK LIST 


1. Debugging techniques employed. 

2. Preliminary phases. 
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a. Flow chart and coding 

b. Clerical errors 

c. Logical errors 

3. Assembling and compiling phases, suggestions 
for improvements. 

4. Phases beyond assembling. 

a. 1108 package adequacy 

b. Other concepts 

c. Suggestions 

5. Testing. 

a. Tests employed 

b. Generating test data 

6. Editing or cleaning-up programs. 

7. Management practices. 

a. Coordination, etc. 

b. Suggestions 

8. On-line debugging. 


2-4 



9. State-of-art . 

a. Techniques 

b . Concepts 

10. Greatest problem in debugging IMP-F, special 
or unusual problems. 

11. Knowledge of debugging literature. 



SECTION III 

CURRENT DEBUGGING CONCEPTS 


3-1. CURRENT CONCEPTS 


This section discusses debugging concepts surveyed 
for future implementation in programs such as IMP-F. While 
the concepts described, here may not be entirely new or 
unknown, and while the list may not be complete, neverthe- 
less these concepts represent a typical range of current 
practices or developments, and as such may suggest known 
approaches to the subject of debugging. 


3-2. PRELIMINARY TESTING 

Preliminary testing, manual checking or desk checking 
consists of a detailed review of the program by the program- 
mer. This phase of testing may be viewed as having two 
parts, the first of which is a review of the general logic 
and degree of completeness . The second part is a manual 
dry run using sample data during which the programmer 
keeps track of register contents, modified instructions, 
switches, etc., while following the flow of the program. 
Special emphasis may be placed on unlikely situations. 


3-3. Checking the Flow Chart 

During this phase of testing, the flow chart can 
and should be utilized both for detecting errors and as 
a logical tool for debugging procedures. The desired 
level of detail for such flow charts would show every 
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decision or branch and every subroutine execution. Seven 
basic checks should be performed on the flow chart. 

a. The beginning and end should be clearly 
marked and present. 

b. Each decision symbol should have at least two 
alternatives, and each possible result of 
the test should be represented by some flow 
line. Such flow lines should be traced so as 
to insure that the correct path is taken for 
the specified condition. Each condition 
should be provided for. 

c. Operation symbols should have no more than 
one exit and entry line. 

d. Flow lines must-be connected at both ends, 
each line must originate at some symbol and 
terminate at a symbol or merge point. 

e. On flow charts of that level of detail which 
includes partial coding, no variable name may 
appear on the right-hand side of a formula, 
in a decision symbol, or as output if it has 
not been defined somewhere in the program in an 
input list or on the left-hand side of a formula 
(any statement calling for the assignment of 
values and quantities) . Each variable name 
which appears at least once in a program in 

an input list (including the outputs of sub- 
routines) or on the left-hand side of a formula 
is unused if it does not appear on the right- 
hand side of a formula, in an output list 
(including the quantities supplied to subroutines 
by the main program), or in a conditional test. 

It is, therefore, unneccessary . 
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f. Switches must be set or defined at some point 
previous to usage in the flow chart, and each 
possible position of the switch must be set at 
least once somewhere on the chart. 

g. Each loop must have the following features: 

1. Initialization. 

2. A process consisting of one or more 
statements . 

3. One or more tests to terminate loop. 

4. A method for reiterating the loop. 

3-4 . Linking the Flow Chart to Coding 

After the programmer is satisfied with the flow chart, 
the coding is performed. During the coding process, care 
should be taken to link the flow chart with the coding. 

If changes in the flow chart are required, the above checks 
should be considered to ensure that new errors have not been 
propagated. 


3- 5 . Concluding Steps of Preliminary Testing 

The preliminary testing phase progresses from a 
rough analysis through more detailed analysis to a detailed 
check of the coding. If time permits, recopying of the 
diagram may be desirable because close reexamination may 
disclose errors previously hidden by sloppy drawing or 
erasing. If time and personnel permit, it is extremely 


helpful if a second person can assist in the preliminary- 
checking procedures. A listing of the cards should be made 
and checked against the coding forms, looking for keypunch 
errors and sequence. 


3-6. ASSEMBLING AND COMPILING 

Computer systems supply a certain amount of diagnostic 
control in their assembly or compilation programs. However, 
this type of diagnostic aid is in most cases designed to 
assist the programmer only up to that time at which the com- 
puter is able to interpret and execute the instruction sequences. 
The diagnostic notations produced usually deal with clerical 
type errors and seldom with logical errors. Some systems pro- 
duce diagnostics that indicate the severity of the error, 
i.e., absolute, probable, etc. An error-free compilation or 
assembly does not indicate that the program is debugged, only 
that certain types of coding errors have been eliminated. A 
weakness of both compiler and assembler debugging aids lies 
with the fact that the statements are examined singly. The 
processor is for the most part unable to detect logical errors 
in transfer of control. 


3-7. Assembler Aids 


Most assemblers produce a program listing with diag- 
nostic notations adjacent to the instruction containing certain 

4 

errors. Errors of this nature include the following: 

a. Undefined or multi-defined symbols. 

b. Invalid operation codes. 

c. Invalid operands in a symbolic expression. 
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d. Invalid or omitted address. 

e. Improper use of certain pseudo-operations. 

f. Invalid names in name field, such as names 
containing unauthorized special characters, etc. 

The diagnostic notations are generally singular. Some 
systems produce two notations in the event that two detectable 
errors occur in a single statement. 

A list of symbol references (the part of a computer 
listing sometimes called an external symbol dictionary, or 
a concordance, or a cross-reference table) may be extremely 
useful in revising as well as debugging a program. In the 
event that a change is made that affects the definition of a 
symbol, it is important that all references to that symbol 
be checked. Special care is required when a coding sequence 
is deleted, since it is likely that one or more symbols may 
be affected. 


3- 8 . Compiler Aids 

The diagnostic notations produced by compiler systems 
are similar to those produced by assemblers. They are 
generally printed with the listing and where possible make 
reference to particular statements. The following summary 
shows typical diagnostics produced by one FORTRAN compiler:^ 

a. Individual statements: 

1. Invalid statement - reserved word, 
excessive length, etc. 
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2. Mixed arithmetic expressions - containing 
real and integer constants and variables. 

3. Misuse of parentheses - an unequal number 
of left and right parentheses. 

4. Illegal expression - two operators may have 
been used in succession, etc. 

5. Subscripting a fixed-point variable. 

b. Interaction of two or more statements: 

1. Referenced statement is not present or 
is unnumbered. 

2. Omission of a DIMENSION statement when 
subscript variables are used. 

3. Undefined variables - a variable that appears 
in an arithmetic expression (on the right 
side of an arithmetic statement) that is 

not defined or assigned a value earlier 
in the program. 

c. Capacity of words or of memory: 

1. Table limits have been exceeded - during 
compilation FORTRAN uses a number of tables; 
if the programmer uses an excessive number 
of statements or other features a diagnostic 
notation results. 

2. Memory capacity of machine is exceeded. 
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Number exceeding precision of computer - 
number too large or too small, requiring an 

+ 70 . 

excessive number of decimal places CIO - ) 
is a typical limit of a 36-bit binary word 
computer. 

d. Logic of program: 

1. Flow is unable to reach at least one part 
of the program because of branches; program 
flow does not include one or more executable 
statements . 

2. Illegal entry to a DO loop - entering a 
DO loop at any statement in the range of 
the loop other than the "DO" statement 
itself. 

3. Excessive levels of nested loops - this 
limit is determined by the individual 
computer . 

A number of these diagnostic notations would be appli- 
cable to any algebraic- language program (a. 3, a. 4, b.l, b.3, 
c.l, c.2, and d.l). Others only apply to FORTRAN and certain 
other compilers (a.l, a. 2, a. 5, b.2, c.3, d.2, and d.3). 

3-9. MACRO- INSTRUCTIONS 
3-10. Debugging Macros 

Certain special macro- instructions may be used during 
the running of an object program to provide debugging informa 
tion that is not normally supplied. Instead of using inter- 
ruptions or trap features, the macro calls are inserted in 
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program. These macro- instructions expand into coding that 
calls for output routines that are under control of the 
operating system. Loops, when required, are also provided 
for by these macro- instructions . The information produced 
may appear in the same form as does a dump or trace. 

Existing machine instructions may be modified by 
macro-definitions to supply diagnostic information. An 
example of this technique is to modify a storage instruc- 
tion so as to write out the data being stored. However, 
a more common technique is the insertion of macro- ins tructions 
in the program for the specific purpose of providing diagnos- 
tic information. 


3-11. Advantages of Debugging Macros 

Particular use is made of the writing or printing 
instructions. Certain condition stipulations may be employed 
as well as format specifications (similar to those in a 
dump) such as hexadecimal, decimal, octal, or BCD. Reassembly 
of the program is required in order to insert the additional 
coding of the macro- instructions , a process thar is not 
necessary with the use of dumps or traces. There are, however, 
several advantages to this technique 

a. Symbolic references may be made to locations 
or blocks of locations that are to be dumped; 
in the event that coding changes are made, there 
is generally no need to change the macro calls, 
which is often the case with control cards when 
using snapshot dumps since their addresses are 
absolute; however, many systems provide for 
symbolic addressing for their dumping routines. 
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b. Flexibility is provided the programmer; he may 
specify any sort of dump he wishes. They may 
resemble traces or dumps or any combination of 
the two. The macro- ins tructions used for dumping 
are generally quite simple in structure, primarily 
involving coding for a loop, for an output calling 
sequence, and for storage of certain registers. 
Because information may be displayed in various 
formats, the dump may include symbolic information 
which facilitates the identification of words 

and registers. 

c. Macro- ins tructions are relatively easy to write. 
The advantage of writing macro-ins tructions for 
dumping purposes over corresponding coding for 

a monitor system or processor is that instructions 
must be general in nature and each piece of 
information must be stored in memory tables or 
remain in instructions to be interpreted. The 
coding employed with the use of macro-instructions 
is specific and is tailored to the user's needs; 
also, the instructions remain in executable form 
within the macro- instruction expansion. 


3-12. The SDC- SHARE Debugging Package 

The debugging package which is included in the SDC- 
7 

SHARE operating system uses a set of macro-instructions 
that will produce selective dumps in the source language 
at any point during the execution of the object program. 

The execution of these macro- ins tructions does not affect 
the operation of the object program. The debugging macro- 
instructions are defined within the compiler and will be 
inserted into locations specified by the object code during 
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compilation. The debugging macro-instructions are classified 
according to three categories: information macros, conditional 

macros, and modal macros. 


a. Information Macros . This type of macro- ins truction 
is responsible for the actual dumping of information. 
This information is written on a tape during the 
execution of the object program after which it is 
translated and written on an output tape. The for- 
mat for the output may be included in the informa- 
tion macro, otherwise it will be described in a 
dictionary by successive location symbols. The 
dictionary is developed during compilation, each 
entry containing a location symbol and a corres- 
ponding format code to identify the contents of 

the described cell in memory. Through the use 
of this dictionary, symbolic output may be produced. 
The format codes control the printout of all 
information from the specified location to the 
location of the next symbol encountered. 

b. Conditional Macros . This type of macro- instruction 
is used to control the execution of information 
macros. These macro- instructions are placed 
immediately before the information macros they 
control; their control is terminated when the 

next nondebugging macro- ins truction is encountered. 
Through the use of these conditional macros, 
a programmer may specify conditions which must 
be satisfied before the information macro can 
be performed. 

c. Modal Macros . This type of macro-instruction 
permits the program to specify the mode to be 
used in interpreting subsequent information, or 
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to set or reset certain parameters used by the 
debugging system. Besides defining the mode of 
operation for either conditional or information 
macros, they also provide internal controls for 
the debugging supervisor and some control of 
output format. Modal macros generally remain in 
effect until countermanded by another modal macro 
or another macro- instruction is encountered that 
sets all modal macros to normal conditions. 


3-13. INSERTING DIAGNOSTIC INSTRUCTIONS 

A relatively simple but effective aid in the debugging 
process consists of inserting throughout the program temporary 
diagnostic instructions which will print out messages that 
display the results of the program at various stages. Generally 
such insertions are placed at the conclusion of program seg- 
ments. This technique will provide information as to the flow 
of the program and it may also be used to indicate program 
status (the existence of an error condition) . In order to 
ascertain the status of the program, various tests are employed. 
Through the use of a test deck (a set of test data for which 
the results at various stages are known) , the area in which 
the program departs from the correct procedure can be detected. 

The messages that are printed out may be used to show 
the overflow of storage blocks or a diverging series of values. 
Externally controlled status reports containing such informa- 
tion as item counts, important results, calling-sequence 
parameters, accession assumptions, pointers, and summary 
totals may be produced. One may devise tests for all para- 
meters and provide meaningful messages. In the event that 
it is not possible to correct the error, it may be desirable 
to allow the system to approximate the interim results and 
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continue, especially in the early stages of the system's 
development. When the preceding condition occurs, it must 
be clearly noted. Options should be available to list 
selected subsets of inputs and outputs from peripheral devices 
to each routine in the system. 

A method of cross - control checking may be provided 
by producing a printout of program assertions at the beginning 
of each program segment and of program expectations at the end 
of each program segment.^ 

The inserted instructions and corresponding messages 
should be coded in some consistent, recognizable way which 
will permit their mechanical removal once the program is 
finalized. 

3-14. DUMPS 

Dump is a term that is generally applied to a listing 
of the contents of a storage device; it may include all or 
part of the internal storage, as well as registers. Dumps 
may be classified into several categories: snapshot dumps 

(dynamic) or postmortem dumps (static) . 


3-15- Postmortem Dumps 


The postmortem dump is performed at the termination 
of the object program. This termination may result from 
some form of error or by intentional instruction. At times 
it may be advisable to list the entire memory except possibly 
the monitor system, since the effects of errors are unpredic- 
table and often wide-spread. In early testing this method of 
dumping may be the only way to ensure that some unsuspected 
influencing factor was not overlooked. 
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3-16. Snapshot Dumps 


The snapshot dump is a selected or dynamic listing 
of registers and specified memory locations printed out 
upon the execution of strategically located dynamic-dump 
instructions (breakpoints or checkpoints). The programmer 
may insert these dump instructions in the program before it 
is run the first time; or he may insert or change them before 
a later run, after errors have appeared. This form of dump 
is useful when the programmer has little or no idea as to 
the location of the program error. If the program has 
previously been segmented, it is relatively easy to insert 
dynamic dump instructions so as to isolate at least the 
earliest error to some particular segment. Then as the 
general location of the error is identified, the snapshots 
(dynamic dumps) are inserted more frequently within smaller 
areas of the segments. Each segment may be checked indivi- 
dually. The snapshot dump is an extremely useful debugging 
aid for the programmer (who should know machine language) . 


3-17. Inconveniences of Present Techniques 

The dumping techniques still widely used today, even 

in some of the most modern and advanced computers, are 

claimed to be obsolete, and produce very inconvenient 
9 

listings. Criticisms of the dumping techniques include 
the following: 

1. If the program has run for some time, earlier 
parts which may be meaningful are lost. 

2. Great amounts of useless information are some- 
times generated. 
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The listings are difficult to analyze. One must 
perform a great deal of decoding; know the main 
characteristics of a particular machine, its 
internal language, the operating system, and the 
object (machine) codes corresponding to instruc- 
tions written in the source language. 


3-18. Efforts to Improve Dumping Techniques 

Various attempts have been made to refine and improve 
the dumping techniques. These are, in essence, attempts to 
overcome the previously listed criticisms. 

a. The use of symbolic address designations for the 
purpose of dumping is provided for by certain 
processor systems. The advantages of this 
approach are evident - consider the advantages 
of symbolic coding over machine language coding. 

In order to facilitate such a technique a symbol 
table associated with the program being debugged 
must be accessible. The dumping routine must 
convert the symbolic addresses on cards to 
absolute addresses. 

b. The operating system must assume temporary control 
from the object program during the time that the 
dumped information is being written out. A common 
way of accomplishing this is through the use of 

a trap. The trap is a special form of a conditional 
breakpoint which is activated by the computer 
itself or by conditions imposed by the operating 
system, or, by a combination of these. The trap 
causes control to pass to a specified memory loca- 
tion within the operating system. A method of 
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returning control to the object program must also 
be provided for. When the operating system 
encounters debugging control instructions, it 
must provide means by which the trap will occur 
at the specified locations. A record must be 
made of the location in the object program from 
which control was transferred to the operating 
system. 

c. The efforts made on improving dumping techniques 
have been directed toward the pinpointing of 
dump locations, increasing the selectivity of 
the storage locations to be dumped, and editing 
of the printed output. 


3-19. The ALCOR Illinois 7090/7094 Post Mortem Dump 

The ALCOR Illinois 7090/7094 Post Mortem Dump (PM- 
Dump) provides an example of improved techniques in the area 
of postmortem dumping. 

a. The objectives of this effort include the 

following : ^ 

1. If the program runs successfully, the 
execution time must not be increased. 

2. Specialized knowledge in excess of what 
was needed to write the program should not 
be required for understanding the data 
provided by PM-Dump. 

3. Events occurring before the failure that 
have a possible influence on its cause 
should be recorded in PM-Dump. 
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4. All information that is not pertinent to 
the determination of the cause of the 
failure should be avoided. 

5. Information pertaining to specific machine 
characteristics should be held to a minimum. 

b. The PM-Dump is not a single program but consists 
of several programs, each of which generally per- 
tains to one of the various stages of program 
processing (translation, loading, execution). 

1. During the translation phase the compiler 
generates dump information which relates the 
object code generated by the compiler to the 
original source- language program. This 
dump information provides the basis for 
failure analysis. Since the information 
which relates the source program to the 
object code is available only at compilation 
time, the compiler must save this information 
The modification of an existing compiler may 
be a difficult and tedious task. The dump 
information is moved to secondary storage 
until later when it is used at dump time. A 
loading map is useful but it is not necessary 
Such a map would be helpful in locating the 
point of failure and in determining how to 
access the proper dump information. 

2. At the beginning of program execution, a 
short routine indicates to the operating 
system where control should be transferred 
in the event of an unsuccessful termination. 
This is the only routine that slows program 
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execution if a dump is requested. The 
routine consists of about 100 machine 
instructions which set switches in the 
operating system or initialize a few error 
routines . 

3. At the time of the failure, the operating 
system transfers control to a connecting 
routine which saves the relevant contents 
of memory (the program and working storage 
areas) for the main dumping routine. This 
routine then calls on the main dumping 
routine and passes to it such information 
as the type of failure and the contents of 
the instruction counter. Because of the 
relatively long length (about 3600 machine 
instructions) of the main dumping program, 
it is desirable to load it into main memory 
only after a failure occurs. This is accom- 
plished through the use of the connecting 
routine . 

4. The main dumping routine coordinates and 
analyzes the information made available to 
it by the previous routines, and presents 
the programmer an analysis of the state of 
the program and of its history at the time 
of failure. The object code at execution 
time is not affected by the dumping routine 
except in the case of one call. During com- 
pilation all preparations are made for the 
dumping process and the analysis is performed 
only after the failure has occurred. The 
dumping routine provides the programmer 

with the following information: 
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(a) Lists local information such as names 
and values of variables and object codes 
which concern the failure point in the 
program. 

(b) The name of the subprogram or procedure 
is listed if the failure point was not 
in the main program. 

(c) A listing of names and present values 
of variables is produced beginning with 
the block in which the failure point 
occurs and proceeding to surrounding 
blocks until all blocks in a given 
procedure have been processed. Unless 
the block terminates in the main pro- 
grams, the point from which it was 
called is determined and is considered 
a new failure point. 


3-20. The UNIVAC 1108 Executive Systems 

The UNIVAC 1108 executive systems provide for both 
postmortem and snapshot dumps. Snapshot dumps may be 
initiated when a source language element is processed to 
relocatable element form or when relocatable elements are 
combined by the collector into an absolute program. Post- 
mortem dumps are initiated by a control statement. Dumped 
information is written in a diagnostic file, and is read 
back for editing after the program being tested has terminated. 
Library subroutines write out dumps, save and restore all 
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of the program's environment. The snapshot facility may be 
employed by any processor. 


3-21. The Snapshot Dump 

The selective nature of the snapshot dump is achieved 
through the use of seventeen procedures. These are divided 
into three categories - conditional, dump, specification. 

a. The conditional procedures may precede or be 
interspersed among a list of dump procedures. 

The purpose of the conditional procedures is to 
determine when or if dump procedures are to be 
activated. 

b. The dump procedure generates a calling sequence 
which writes out the information comprising the 
desired dump. If no conditional procedures are 
used, the dump procedures will always produce 
output. These instructions enable the programmer 
to select the locations and amount of information 
to be dumped. 

c. The specification procedures provide a buffer 
area and format specifications. A number of 
standard formats are provided by the system and 
these would suffice in most cases; however, for 
unusual situations, one may define special formats. 
An area of core is defined into which information 
from tapes or drums is read. The programmer is 
also able to save dumps up to a certain point in 
execution and then delete them at his discretion. 
The overall control of calls to debugging proce- 
dures is maintained by two instructions which 
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activate or deactivate references made to the 
debugging procedures . 


3-22. The Postmortem Dump 

Each diagnostic routine that is part of the program 
is processed serially. A common exit in diagnostic library 
routine will check to see if the next instruction is a call 
to the diagnostic system. This technique ensures that a 
series of calls will not be interrupted by the activities 
of another subprogram. 

The postmortem dump executive control statement is 
used to dump current core memory following the execution of 
a task. These dumps may consist of overlay segments, elements, 
or specified parts of elements. Several options are available 
to the programmer for selecting output format and defining 
core areas to be dumped. 


3-23. TRACES 

A trace is an interpretive diagnostic technique which 
provides an analysis of each executed instruction resulting 
in a listing of such information as the contents of words 
and registers as they are modified and the order in which the 
instructions are performed. This technique does not require 
recompilation and is particularly useful for the programmer 
who is having difficulty following the logic flow since the 
trace provides a means by which one may follow the course of 
a program as it is executed. 
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However, a detailed trace producing a line of informa- 
tion for each instruction greatly slows down the execution of 
the program and generates enormous and excessive listings. 

This approach, particularly diastrous on large systems, is 
generally discouraged and reserved for use as a last resort. 

Another problem associated with the tracing technique 
is the lack of flexibility of many systems in that the pro- 
grammer cannot provide his own subroutines for extended usage, 
therefore, the system software must provide the capability 
for selective or conditional tracing techniques. Because of 
the increasing sophistication of both computer hardware and 
software, as exemplified by address indexing, indirect 
addressing, automatic allocation of relocatable subroutines, 
numerous resident monitor and library routines, paging, 
chaining, and both manual and automatic overlay facilities, 
there are increasing difficulties in following the flow of 
a program, so that it is often desirable for the system soft- 
ware to have an efficient trace routine available. 


3-24. Possibilities for Limiting the Trace 

Possibilities for limiting the trace include the 
following : 

a. Tracing only a single type of instruction such 

as storage, loading, arithmetic, branching, index, 
shifting, skipping, or in^ ut/output instruction. 

b. Tracing a combination of thes ^ specified 
instructions . 

c. Tracing only address modification. 

d. Limiting the number of tracings performed on a 
single loop. 
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e. Tracing in only selected parts of the program 
while other parts run at normal speed. 

f. Tracing only a single register or combination 
of registers. 


3-25. Trapping 

As in the dumping technique, the operating system 
must assume temporary control from the object program during 
that time the diagnostic information is being written out. 
This is generally accomplished through the use of hardware 
interrupts or interpretive software routines (traps) . 

The IBM 7090 provides a special transfer trapping 
mode which enables the object program to run at normal speed 
and to slow down only when a transfer is executed and diag- 
nostic information is written out. While running at normal 
speed the flow of control passes sequentially from one 
instruction to the next, except in the case of a skip after 
which it passes to the next instruction. This technique 
is particularly useful when one is only trying to establish 
the structure of the program. 


3-26. Static Trace 


A static trace technique was developed by the Mitre 

1 2 

Corporation for use on the IBM 7090. It is referred to 
as the Masked Search Program. Through the use of specifi- 
cation cards, the programmer specifies a mask and a block 
of storage to be searched by the program. The Masked Search 
Program then lists the locations that are in accordance with 
the specification cards. An address mask may be used to 


5-22 



identify all locations that are related to a particular entry 
point in a subroutine; after obtaining a list of the locations 
having this entry point as their address, a listing of the 
storage area being searched would normally tell where in 
the search area the subroutine is being entered. Through the 
use of an op- code mask the programmer can locate all instruc- 
tions which change memory. One may also determine how certain 
storage locations are used. 


3-27. Improved Approach to Tracing 

An approach increasing the speed and efficiency of 

13 

trace techniques is presented in a paper by Eugene I. Grunby. 
This approach is basically an attempt to allow the programmer 
to exercise his skill and ingenuity in developing the trace 
routine, and to provide flexibility in the selection of 
subroutines thereby eliminating unwanted processing. 

The method of allowing for this flexibility in 
selecting subroutines is based on the use of a single trace 
routine which makes available the same basic information to 
each of a number of subroutines. The basic information pro- 
vided by the trace routine generally includes the origin 
and destination addresses that represent a change in sequen- 
tial addressing. This approach enables the subprograms to 
be independent. A set of subprograms each of which serves 
a specific function may be developed. Each of these sub- 
programs may call another, thus a composite of functions can 
be selected to meet task requirements. The programmer is 
able to select standard subprograms in any combination or 
he may construct his own. 

Mr. Grunby 's approach also includes a method of 
eliminating excessive and useless printout. The first step 
is to eliminate all but the most essential information, the 


3-23 



addresses or origin and destination involved in a branch 
instruction. A second step involves the use of a cyclic 
table. Trace information is stored in a core table and is 
used for a selective listing at the end of the job, but 
because of the limitations of memory available, the trace 
information is stored on a cyclic basis, overlaying from the 
top to bottom. Options should be provided to allow the pro- 
grammer to select the length of the table and make the most 
efficient use of this limited storage area. Thirdly, use of 
format options or other options which maximize output on the 
printed line and that are generally supplied by most systems 
should be employed when the table is being listed. 

Among the most significant applications for the tracing 

technique just described (as implemented on the UNIVAC 1107) 

14 

are the following: 

a. Dumping of preselected memory locations at the 
time of each traced instruction. 

b. Continuous testing for branches to invalid 
destinations, and initiate an error routine when 
the event occurs. 

c. Continuous testing to determine if and when an 
instruction or I/O operation is exceeding 
storage limitations and which one is at fault, 
and initiation of an error routine when this 
event occurs. 

d. Computation of the distribution of operation 
codes in executing program; it may at the pro- 
grammer's request include library and resident 
monitor routines. 



e. Continuous detection and recording of points 
where characteristic overflow, characteristic 
underflow, divide overflow, occur. 

f. Combinations of the preceding applications. 


3-28. The SEFLO Tracing Technique 

SEFLO, SEquence-FLOw, 15 a tracing technique, is 
described in a paper by Abrom Hisler. This technique may 
be used either for FORTRAN V or SLEUTH II on the UNIVAC 
1108. SEFLO enables the programmer to follow changes in 
contents of selected registers and storage locations. The 
package consists of two subroutines and the sequence cards 
which call for the contents of trace whenever requested 
during running of the object program. 


3-29. DYNAMIC DEBUGGING 

Tracing and dumping each has its advantages and limi- 
tations. Any concept that employs the advantages of each in 
a single technique can be referred to by a number of titles, 
but for the purpose of this discussion shall be referred to 
as dynamic debugging. This concept implies that the process 
takes place as the program is in progress and that a certain 
degree of analysis is performed, producing diagnostic informa- 
tion in addition to a listing such as that produced by traces 
and dumps. 16 The basic concept of dynamic debugging is simply 
to provide the programmer with a snapshot- type dump each time 
that predefined criteria are met. 
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The main restrictions placed on dynamic debugging are 

the resultant size of available memory and the ingenuity required 

of the programmer writing the analysis program. The following 

is an illustrative list of the diagnostic information this technique 
1 7 

may provide. 

a. Contents of the location counter, showing the 
current location of the program. 

b. Contents of all other control and arithmetic 
registers along with the status of such things 
as overflow indicators. 

c. Contents of certain memory locations or blocks 
of locations. The option to specify mode and 
format may be desirable; the locations and 
formats are specified in the debugging program 
and formats are likely to change from one point 
in the program to another. 

d. A record of the occurrences of a certain condition, 
as tallied in a counter. Through the use of 

such a counter, parameters may be specified for 
various tests, i.e., listing will be produced 
a certain number of times or not produced until 
after the condition has occurred a specified 
number of times. 

e. A record (desirable under certain circumstances) 
of a specified number of the last executed 
branches . 
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3-30. FORTRAN Debugging Languages 


Since FORTRAN was used, on the IMP-F project and is 
particularly applicable to this type of programming, it is 
well to consider more specifically those debugging aids 
associated with FORTRAN. Since the compiler naturally checks 
for simple clerical errors, and since the FORTRAN language 
is essentially closed with respect to vocabulary, syntax, 
and structure, the compiler is able to check the basic tests 
outlined in discussions of preliminary testihg. 


3-31. One FORTRAN Debugging Language 

Since earlier FORTRAN compilers did not include an 

independent debugging facility, this often forced programmers 

to rely on the machine language for diagnostic purposes. A 

1 8 

debugging language in a FORTRAN format is now available. 

This language was designed so that reference may be made to 
specific statements within the body of the FORTRAN program 
without becoming an actual part of that program. Many of 
the statements in the FORTRAN language itself such as GO TO, 
CALL, RETURN, and STOP are included in this system. Much 
use is made of subroutines. Conditional situations are 
particularly applicable to the use of logical IF statements. 
The DUMP statement provides a convenient method for printing 
out information when there are no particular format require- 
ments. The DUMP statement, much like the FORTRAN READ and 
WRITE statements, specifies a list of information to be 
listed; these specifications may be within the statement or 
in another statement referenced by the DUMP statement. 

Through the use of a Hollerith field or quotation marks one 
may provide notes or messages with the information listing. 
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The LIST statement enables one to reference the same 
information by more than one DUMP statement without repeating 
a list with each DUMP statement. When necessary one may dump 
the entire program with the statement LIST PROGRAM. One may 
cause dumps at certain intervals, thus limiting the amount 
of output through the use of an ON statement. 

A single card must proceed each debugging request or 
group of debugging requests. This card may set maximum limits 
on the number of requests honored, regardless of type and the 
maximum number of lines that may be printed, all other diag- 
nostic information being lost. This control card almost forces 
the programmer to set explicit limits on his debugging request. 
However, the limit control features may be left off of the 
control cards; thus, no upper bounds are set. 

Since this FORTRAN debugging system allows the execu- 
tion of a program composed of many parts and having been 
compiled separately, it is necessary to specify not only which 
statements are to be affected, but in which subprogram (function 
or subroutine) those statements are to be found. Each sub- 
program is referenced by its name. A code is used to indicate 
that there are no more debugging requests. 


3-32. DIAGNOSE, Another FORTRAN Debugging Language 
19 

DIAGNOSE is a debugging program that is used to 
detect the following three common errors which occur during 
the execution of FORTRAN-63 programs. 

a. Erroneous subscripts. 

b. Undefined variables. 

c. Erroneous DO- loop parameters. 
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When one of the above conditions occurs during the 
execution of a program, operation is halted and an error 
message written on a standard outpu.. unit and an error 
routine is activated for dumping purposes. The error message 
is composed of a statement number, variable name, and type 
of error. 

The input when operating with DIAGNOSE consists of 
source decks, binary decks, and data. DIAGNOSE produces a 
new souce deck by inserting calls to certain library subrou- 
tine in the original source deck. The logical flows and the 
program results are in no way affected up to the point at 
which the error occurs. 

DIAGNOSE makes two passes through the source deck, 
as follows : 

a. The first pass produces four lists and outputs 
part of the original program along with other 
information and a scratch tape. The four lists 


are 

• 


1 . 

Arrays and dimensions. 


2. 

Statement numbers . 


3. 

Terminal statement numbers and DO 

loops . 

4. 

Statement numbers of replacement 
statements . 

and CALL 

The second pass performs analysis on DO statements 
replacement statements, IF statements, and CALL 


statements. During the second pass adjustments 
are made on statement numbers to insure that the 
flow, of the program remains unchanged. For each 
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of the above statements, DIAGNOSE may insert CALL 
statements to two or more routines that do the 
following : 

1. Identifies statement currently being checked. 

2. Checks subscripts. 

3. Checks the value that has been assigned 
to a particular variable. 

4. Checks variable parameters of a DO loop. 

DIAGNOSE produces an intermediate program that will 
require approximately twenty percent more memory and roughly 
doubles the running time of the original program. DIAGNOSE 
requires a compilable program (one that is free of syntax 
errors) . 


3-33. BUGTRAN, Another FORTRAN Debugging Language 
20 

BUGTRAN is another debugging system that applies to 
FORTRAN. The checkpoint method requires nearly exact inter- 
mediate results which are frequently unavailable; and the 
trace routine, as it is commonly used, is cumbersome and 
experts ive. Thus, BUGTRAN was developed to help overcome 
these shortcomings. 

a. The BUGTRAN system includes a variable trace, 

flow trace, trace of program entries and exits, 
snapshot dumps, conditional termination of the 
program, and an option to print the comments of 
the source program. The option to apply BUGTRAN 
to only specified parts of the program is provided 
for. The system does not place any requirements 
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on the compiler, such as generating symbol tables, 
or affecting the operation of the program. A 
mechanical means of removing the debugging from 
the program is also provided for. The following 
is a summary of BUGTRAN features: 

1. Check Variables - a list of variables is 
specified in a BUGTRAN control statement. 

If one of these variables appears on the 
left-hand side of an arithmetic substitu- 
tion statement or as the index of a DO 
statement, it will generate a call to the 
BUGTRAN output routine. 

2. Check Flow - all GO TO, ASSIGN and IF 
statements generate calls to the BUGTRAN 
output routine. 

3. Dump - a statement number along with the 
variables to be dumped is specified in a 
BUGTRAN control card. The dump is executed 
immediately before the execution of the 
specified statement. This is accomplished 
through a generated call to the output 
routine . 

4. Check Entries - a call is generated to the 
output routine each time that a SUBROUTINE, 
FUNCTION, END or RETURN statement is 
encountered. 

5. Print Comments - all comments generate a 
call to the BUGTRAN output routine, causing 
the comment to appear in the output. 
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Terminate - a statement number and a con- 
ditional IF clause are specified on a BUGTRAN 
control card. The condition is tested 
immediately before the execution of the 
specified statement, and if the condition 
is satisfied the program is terminated. 

b. A syntax table approach is used to interpret the 
FORTRAN and BUGTRAN statements. A syntax table 
is first used to interpret the BUGTRAN control 
cards. Another syntax table is then generated 
based on the type modifications specified by the 
control card to process the FORTRAN statements. 
Only those FORTRAN statements which are specified 
are provided for in the syntax table. The major 
advantages of the syntax table are the following: 

1. It is possible to use the same scanner to 
recognize the various types of statements 
by merely changing the syntax tables. 

2. Changes in the source language require 
modification of the syntax tables only. 

3-34. TESTRAN, IBM System/360 
3-35. Introduction to TESTRAN 

TESTRAN*^, or test translator, is a facility offered 
by the IBM System/360 Operating System. TESTRAN aids in 
detecting faulty logic by providing printed information con- 
cerning the actual operation of the program. This facility 
describes the changing contents of storage areas, registers, 
and control blocks, and shows the manner in which control 
flows from one group of instructions to another. 
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Requests for TESTRAN services are coded in a TESTRAN 
source module. Each of these statements is a coded TESTRAN 
macro-instruction, which is replaced with a series of con- 
stants by the assembler. In effect, these constants aire a 
control statement that directs the TESTRAN interpreter to 
perform a specific operation. The decision to perform the 
next sequential macro- instruction or a logical branch to 
another macro- instruction is determined by the operation 
being performed. 


3-36. Procedure 

The structure of a TESTRAN statement resembles that of 
a basic assembler language statement. Every statement includes 
an operation code and one or more operands. A symbolic name 
may precede the operation code and a comment may follow the 
operands. The operation code and first operand combine to 
define the type of operation to be performed and are used as 
generic names for statements. 

a. The general functions of TESTRAN statements are 

the following: 

1. Recording functions which provide dumps and 
traces of the problem program. 

2. Linkage functions which control linkage to 
the TESTRAN interpreter. 

3. Decision-making functions which provide 
condition testing and condition branching. 

4. Branching functions which provide uncondi- 
tional branching and subroutine capabilities. 
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5. Assignment functions which control values 
of variables in the problem program and of 
special variables used in decision making. 

b. During execution, TESTRAN is able to test for 
predefined error conditions and take corrective 
action when necessary. Usually, after corrective 
action is first taken, the final results of the 
program are still erroneous, but continued pro- 
cessing would permit the possibility of finding 
the additional errors. 

c. The TESTRAN statements are combined with the pro- 
gram to be tested by either of the following 
methods : 

1. The TESTRAN and the problem program source 
modules are assembled together and result 
in a single module. 

2. The TESTRAN and the problem program source 
modules are assembled separately, resulting 
in separate object modules; these are then 
processed by the linkage editor to form a 
single load module. 

d. The single load module is then loaded and executed. 
Requests for testing services are interpreted by 
the TESTRAN interpreter which is a part of the 
control program that receives control during 
program interruptions. Test information along 
with control information copied from the unloaded 
form of the load module is placed in a TESTRAN 
data set by the TESTRAN interpreter. 



e. The TESTRAN editor prints the test information 

in the form of dumps and traces. Like the assembler 
and the linkage editor, the TESTRAN editor is a 
processing program that is executed as a job step. 

It puts test information into a meaningful symbolic 
format by using control information copied from 
the load module. This control information includes 
symbol tables and a control dictionary for each 
object module that is part of the load module. 

Both the control dictionary, which is produced 
as a standard feature of the assembler, and the 
symbol table, which is an optional feature of the 
assembler, are placed in the load module as an 
optional feature of the linkage editor. 


3-37. The "Rip Stopper" Method 

A major part of the conventional debugging effort 
rests in going back from that point at which the error mani- 
fests itself to its point of origin. Frequently, the faulty 
program destroys the information that would permit tracking 
activity. A concept that would permit the identification of 

an error condition in time to preserve the necessary diagnos- 

2 2 

tic information is presented in a paper by Mark Halpern. 

The "rip stopper" concept, presented by Mr. Halpern, 
requires a processor that is able to operate in two modes 
(debugging and production) . During operation in the debugging 
mode, the processor would require the following programmer- 
supplied information: 

a. Minimum and maximum limits, and where appropriate, 
increment size for each numerical variable in the 
program. 

b. Limits within which transfers are legitimate. 


3-35 



While operating in the debugging mode, all computation and 
transfer of control would be executed interpretively . If 
any limits are violated, action specified by the programmer 
is initiated. 

Provision should be made for the option to generate, 
upon demand, coding that is interpretively executed, like 
that produced by the debugging mode, with the purpose of 
computing the execution time of the compiled instructions 
rather than testing their validity. 

The print-out of diagnostic information should be 
structured, interpreted, captioned, and ordered so as to 
follow the steps taken in normal debugging procedures. Tables 
should be in tabular form, character strings in linear form, 
numerics in the appropriate external format and base mode, and 
labels and comments should be used freely. Parts of a single 
logical item that are scattered throughout the memory must 
be collected and presented in a unified form. 


3-38. The WATCHR III System 

An excellent example of a comprehensive debugging pack- 
23 

age is the WATCHR III system that was developed at New York 
University for the CDC 6600 computer. It has the ability to 
provide traces of selected instructions or of all instructions, 
of changes affecting selected variables, of flow of the object 
program, of changes affecting selected registers, of selected 
loads, and of selected subroutine calls. Traps may be provided 
on selected addresses, selected locations stored into, selected 
addresses loaded from, and selected operation codes. Provision 
is made for dumping part of core at any time and anywhere within 
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the field length, and all of the user's registers at any time. 
The dump may be in octal, integer, floating point, or alpha- 
numeric; excessive duplication is suppressed. Error checking 
facilities are provided for out-of-bounds jumps, memory 
references, arithmetic errors, etc., indefinite and infinite 
results, invalid stores and loads, infinite loops, incorrect 
values for selected variables. When an error condition is 
encountered, a trace of the preceding 600 instructions is 
automatically given. .The WATCHR III system makes provision 
for the user to examine core or registers during the run, and 
for recovery if fatal errors occur. 

The system will operate on any central processor binary 
code, simulates the action of the CPU, and collects information 
as directed by switch settings. At any time switches may be 
set or unset, selections may be made. Also at any time the 
object program may be placed under or removed from under 
WATCHR’ s control. 

The following is a summary of WATCHR III features and 
24 

options : 

a. Traces : 

1. Instruction trace - instructions may be 
selected by means of their operation codes 
for tracing; any operation code or combina- 
tion of operation codes may be selected for 
tracing . 

2. Register trace - registers in any combina- 
tion or order may be selected for tracing. 
Thereafter, whenever a selected register 
acquires a new numerical value, both the 
old and new values are printed out. 


5-37 



3 . 


Program trace - the logical flow or sequence 
of instructions is made available through 
the use of the MAP option. Pairs of 
addresses will be printed out periodically. 
The occurrence of a branch is indicated with 
starting of a new pair of signals. 

4. Memory reference (load) trace - analogous 

to the trace of changed locations except that 
it provides for a long comment giving the 
function served by the variable being loaded. 
The purpose of this feature is to enable 
the programmer to see how the program under 
observation actually operates. 

5. Subroutine call trace - analogous to the 
register trace. Return jumps are traced and 
space is provided for comments denoting the 
purpose of each subroutine. 

b . Traps : 

The trap is used to initiate the trap routine. 

A trap routine is any instruction or set of 
instructions the programmer may wish to execute 
if trap conditions are satisfied. Traps always 
occur before execution of the instruction in 
question. Any number of traps may be set and 
they will be able to operate simultaneously. 

1. Trap on operation code - the programmer may 
assign the starting address of a trap rou- 
tine to any operation code or combination 
of operation codes. 


3-38 



2. Trap on address - when program control 
arrives at a specified address a trap rou- 
tine is initiated. 

3. Trap on storage into a specified location - 
analogous to a trap on address except that 
the addresses selected are locations into 
which stores may be made or are expected 

to be made. 

4. Trap on load from a specified location - 
analogous to a trap on storage into a 
specified location except that the address 
chosen is to be trapped on when its con- 
tents are loaded into a register. 

c. Reports : 

1. Snapshot dump - a parameter list is used to 
dump current contents of selected locations. 

2. Interpreted dump - this dump may be called 
on as often as desired and may be in octal, 
integer, floating point, BCD, or alpha- 
numeric. Provision is also made for giving 
an alphanumeric label to each dump. 

3. Reports - these are given automatically when 
a fatal error is encountered. Reports con- 
sist of the following: 

a. Up to 50 most recent branch instructions. 

b. Up to 50 most recent return jumps. 
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c. Up to 50 most recent stores. 

d. Up to 600 most recent executed instruc- 
tions . 

A program running under the control of WATCHR III 
will take from 40 to 300 times longer. WATCHR III requires 
16K of control memory. The number of test runs required in 
the preparation of a program should be about 5 times less 
with the judicious use of the package. With the employment 
of WATCHR III the overall usage of computer time should be 
less than or equal to the total computer time used without 
WATCHR III. The total program preparation time should be 
shortened by a factor of 5 to 10. 


3-39. TIDY AND EDIT FOR FORTRAN 

Two programs have been developed for the purpose of 
editing FORTRAN programs . The employment of such programs 
would greatly facilitate future changes in the program and 
the debugging of such changes. The correction of errors that 
appear after the program has been in operation for some time 
would be greatly simplified. The following is a summary of 
these two systems. 


3-40. The TIDY Program 
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TIDY processes the old FORTRAN program routine-by- 
routine, and prepares and punches a new version of the pro- 
gram. The new program has the following characteristics. 

a. Statement numbers are left- justified and in 
ascending consecutive order. 



b. Only those statements which are referenced by 
other statements are assigned statement numbers. 

c. Statement number references are updated to con- 
form to the new statement number assignments. 

d. FORMAT statement are collected from within the 
body of each routine and placed at the end. 

e. The only FORMAT and CONTINUE statements retained 
are those that are referenced within the routine. 

f. Spaces are deleted or inserted as necessary to 
ensure uniformity and improve readability. 

g. Comment cards are inspected for comments starting 
in the statement number field; if found, they 
are right-shifted so as to start in column seven. 

h. Consecutive blank comment cards in excess of two 
are deleted. 

i. All statements in each new routine are labeled 
in card columns 73 through 79 with a unique 
letter-number combination. The alphabetic 
character (s) indicate routine, while the number 
indicates the position of the statement in the 
routine . 

j. Column 80 of each END statement is punched with 
a " - " sign (11 punch) . This will permit 
automatic page ejection when listing TIDY- 
processed routines on machines that have the 
"x-skip" feature. 
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k. Certain FORTRAN II statements are rewritten as 
FORTRAN IV statements. 

A number of options are available which enable one to 
modify some of the above characteristics. In addition to 
the editing function, TIDY offers a limited set of diagnostics. 
Errors and trouble areas such as missing or duplicate statement 
numbers, incorrect parenthesis counts, illegal DO- loop indexing, 
illegal statements, and inaccessible parts of the program are 
noted. Pseudo- statement numbers are generated when references 
are found to nonexisting statement numbers to enable the pro- 
grammer to make corrections with a minimum of repunching. 

One option provides a list of corresponding old and new state- 
ment numbers. 


3-41. The EDIT Program 

9 f\ 

EDIx is very much like TIDY. Characteristics a, d, 

f, g, and j of TIDY are also performed by EDIT. The major 

emphasis of EDIT deals with the renaming of variables. The 

variable names used in writing FORTRAN programs often make 

the flow of the program hard to follow. Natural conditions 

which are largely responsible for the above condition include 
27 

the following: 

a. Programmers may use variable names that are 
convenient to work with but are devoid of 
meaning . 

b. Awkward expedient variable names often result 
from hasty changes made during the debugging 
phase . 
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c. Poor selection of variable names was made 
initially, but later, after the program is 
almost completed, the programmer arrives at 
a greatly improved symbolism that he would 
prefer to use. 

It is often desirable to change the names of variables 
but this would entail an amount of work that is in excess of 
the value gained. However, EDIT provides a simple solution 
as detailed in source document. 


3-42. AUTOMATIC FLOWCHARTING 

Recently, various proprietary systems have been put 
on the market that aid in debugging the original source pro- 
gram and provide documentation, by generating from the source 
program a flowchart and diagnostics that give a picture of 
the program logic in its earliest stages, even before assembly 
if desired, thus facilitating debugging. 


3-43. The AUTOFLOW System 
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One of these flowcharting systems is called AUTOFLOW , 
marketed by Applied Data Research, Inc. AUTOFLOW can generate 
flowcharts directly from source programs written in assembler 
language, FORTRAN, or COBOL. The input to the computer is 
the AUTOFLOW program and the user's source deck (or tape) ; 
the resulting computer printout is a flowchart using standard 
symbols (decision, processing, connectors, terminals, etc.), 
plus a listing of the cross-reference table, and a listing of 
diagnostics (if any). The program comments become a signifi- 
cant part of the flowchart. 



This type of flowchart can make instantly visible to 
the programmer any errors in missing destinations in branching 
instructions, undefined external references, errors in address 
arithmetic, etc. 

After the initial flowchart has assisted in correcting 
the coding, then the programmer has the option of improving 
the clarity of the flowchart for final documentation by 
repunching and rerunning the deck, adding special chart- 
oriented codes to the assembler language, FORTRAN, or COBOL 
cards. Through the use of these codes, the level of the 
flowchart detail may be made more meaningful. 


3-44. TESTING 
3-45. Purposes 
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Program testing has two basic purposes. 

a. To insure that the program has been coded 
correctly and that the coding matches the 
logical design. 

b. To insure that the logical design matches the 
basic requirements of the task as it is 
defined in the job specification. 

As each segment of the program is developed, rigorous 
test data should be prepared and that segment should be 
tested. After testing each segment separately, the entire 
sytem is ready for testing. 



3-46. Problems 


The fact that the program is operative and runs to 
a satisfactory completion does not insure that all of the 
exceptional conditions, and their permutations and combina- 
tions, have been tested. The consideration of exceptional 
and unusual conditions frequently accounts for a large per- 
centage of the program's instructions. Unless one is careful 
to provide for these exception conditions in his test data, 
it is quite possible to reach the end of the program while 
checking out only a small proportion of the program. Because 
of the many combinations and permutations of conditions 
inherent in a given program, it is practically impossible 
to test all conditions which may actually occur. Thus it 
is not uncommon for a program that has been operating success- 
fully for some time to fail one day due to an unusual set of 
conditions . 


3-47. Logical Tree 

The use of a logical tree can be a valuable aid in 
selecting the various combinations of input data for testing 
purposes. This technique also aids in locating program 
errors. The systematic formulation of test data will eliminate 
duplication of test situations and will significantly expand 
the number of different test conditions. Through the systema- 
tic selection of all realistic combinations of input data, 
the programmer may test all segments of a given program. 


3-48. Maintaining Test Data 


It may be desirable to maintain a test sequence that 
may be run periodically. One cannot assume that a feature 
which worked on one version will work on another. It may 
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also be desirable to provide a set of test data that will 

31 

generate most system error diagnostics. 

3-49. Satellite Test Data 


Data that are used in testing programs that are to pro- 
cess satellite telemetry data are derived from the following 
32 

sources . 

a. Data generated manually by the programmer. 

b. Data acquired from the satellite during 
ground testing. 

c. Actual data tapes from previous satellites which 
have the same basic telemetry format. 

The first two sources have a major limitation in that 
the test data produced do not reflect adequately the actual 
perturbations present in telemetry data. The third source 
partially overcomes the above limitations but it too is of 
limited utility. Often none of the data available from pre- 
vious satellites have a suitable format or have been obtained 
via the same set of data links as the given satellite. Also 
information concerning the specific type and location of noise 
perturbations in a given data tape is not available to the 
programmer. Thus the program may not detect a particular 
perturbation in the data and the programmer will be unaware 
of this deficiency. 
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3-50. Data Simulation Computer Program 


Because of these shortcomings and the necessity of 
high reliability, another source of data has been developed - 
Data Simulation Computer Program. The benefits derived 
from this program include the following: 

a. Test data will be provided that realistically 
take into account the various specified noise 
conditions . 

b. An increased degree of reliability other than 
achieved through the use of other sources . 

c. Time and effort spent in generating test data 
is reduced. 

d. Reduction in clerical and keypunch errors. 

e. Reduce time of testing cycle. 

f. Useful criteria for accepting contractor- 
produced programs. 
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The Data Simulation Program was written for the 
UNIVAC 110 7 computer. A high degree of flexibility x^as 
incorporated to provide for differences in telemetry systems 
and formats, varying degrees and types of noise conditions, 
variations in experiment-data characteristics, differences 
in formats, etc. The user provides a deck of punched cards 
containing all definitions and parameters for the simulation 
along with user subroutines for special computations . The 
primary output is a digital tape which contains the simulated 



test data. A secondary output is a listing of input para- 
meters, selected data channel and record printouts, errors 
inserted during simulation, and summary statistics for each 
simulated file. 


3-51. PROGRAM CORRECTION 

Basically there are two approaches to program correc- 
tion - re-compilation and load-time patching. When a large 
program and a small error are involved, re-compilation is 
inefficient and is of greater expense than the correction 
warrants. Load- time patching does not provide a listing 
thus the documentation does not match the card deck. For 
the programmer who knows only the higher- level language 
there is no choice, he must re -compile. The option is avail- 
able to the programmer who has the program listing and knows 
the assembly language. 

A third possibility for making program corrections 
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exists. This approach employs a miniature assembly pro- 
gram, packaged as a closed subroutine, which is loaded with 
the object program that is to be corrected. The routine 
is activated by the programmer who specifies the input and 
output buffers and key words which indicate patching loca- 
tions in the input stream. The key-word signals that a 
patch location follows; the input stream is diverted to a 
work area, where the symbolic language patch is assembled. 
When the key word for the end of the patch is encountered, 
control will be transferred to the patch or back to the 
object program as directed. 

Several advantages are incurred through the use of 
this subroutine technique. It is faster than either of the 
other two techniques and it provides documentation. Another 
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advantage over the two conventional methods is that it is 
not confined to unconditional load-time changes. It may be 
called upon to modify the object program at any time during 
the run, and these changes may be made contingent on any 
condition that may be tested by the programmer. Several 
versions of the same procedure may be tested during one run, 
this is made possible by having the constant availability 
of an assembler. The reduced turn- around time can be an 
important consideration. 


3-52. RESTARTING 

An area closely related to testing is that of 
restarting. Often much time and expense may be saved by 
allowing for the restarting of a program at various points. 
By employing this technique one does not need to start at 
the beginning of the program each time an error condition 
occurs. The technique of intermittent restarting may be 
implemented by incorporating a sequence of checks, perhaps 
at the end of each segment. If any of these checks reveals 
an error at that point, operations should cease and the 
program restarted at the last point that was known to be 
correct after corrections are implemented. In the event 
that a program is to be restarted at an intermediate point, 
due to an error check stop, operator mishap or machine 
malfunction, it is necessary to save information about the 
status of the program at that point. Such information would 
include the contents of all memory storage areas, both 
internal and external. One approach to saving this informa- 
tion is to dump memory at every check point, always saving 
the last dump . Upon restarting, this information would be 
relocated. 
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SECTION IV 
ON-LINE-DEBUGGING 


4-1. ON-LINE DEBUGGING TECHNIQUES 

Although the main emphasis of this paper is intended 
to be on conventional or batch debugging, some mention of 
on-line debugging is in order. The current consensus among 
computer professionals is that on-line applications repre- 

*7 

sent the wave of the future. On-line computer activity 

probably represents about one percent of the total present 

computer activity; however, in five years it may represent 

fifty percent and in ten years it may represent nearly all 
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computer activity. 

On-line debugging is conducted by a programmer who 
is in direct communication with the computer. The type- 
writer or teletype is most commonly used. The programmer 
makes changes, tests, then again makes changes in a continu- 
ous process with quick response from the computer until 
satisfactory results are achieved. On small computers or 
in the early days of computing when the computer was com- 
pletely dedicated to the programmer and his program, the 
on-line ("hands-on") mode of debugging was a standard prac- 
tice; but now it is not used as much, where programs are 
run "remote" on large computers. However, the arrival of 
large-scale time-sharing systems has made this mode of 
operation feasible on large computers. 

Much of the work done in the area of on-line debugging 

has been described only in unpublished reports or passed 

on orally. However, an excellent paper by Thomas G. Evans 

and D. Lucille Darley presents a survey of on-line debugging 
3 8 

techniques. Included in their paper are some possible 
future developments as well as a list of references. 
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4-2. 


CRITERIA FOR AN ON-LINE DEBUGGING SYSTEM 


The following principles may be considered as good 
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criteria for an on-line debugging system. 

a. Flexible control over the program must be pro- 
vided to the programmer. The programmer must 
be able to specify this control in terms of 
natural units, small and large, of the language 
in question and be able to carry this control 
down to the finest level of detail. 

b. Using the notation of the language of' the pro- 
gram the programmer must be able to examine 
and "incrementally" modify both data and pro- 
gram at any time. 

c. The debugging control language should be 
designed so that a minimum of typing is required 
and information provided the programmer is com- 
patible, concise, and aids rapid comprehension. 

d. Provision should be made for the automatic 
updating of the user's symbolic file to reflect 
the in-core representation of the program. 


4-3. THE PROGRAMMER-CONTROLLED BREAKPOINT 

Perhaps the central notion of on-line debugging is 
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the programmer-controlled breakpoint. This concept allows 
the programmer to specify, generally in symbolic forms, a 
point or points in the program at which he wishes to inter- 
rupt the flow and return to the debugging routine. Upon 
entering the debugging routine, the sthte of the active 
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registers is stored in order to permit subsequent continua- 
tion from the breakpoint. The programmer examines his pro- 
gram at this breakpoint and may make any desired changes 
before continuing. 


4-4. ASSEMBLER- LANGUAGE PROGRAM DEBUGGING: THE DDT SYSTEM 

When considering on-line debugging facilities a 
separation may be made between those that deal with the 
assembler language and those that deal with higher level 
languages . 

4 1 

DDT (Digital Debugging Tape) is one of the better 
known on-line debugging programs that deals with an assembler- 
language program. One of the most important characteristics 
of this program is the care devoted to the design of the 
typing conventions. Single- letter commands and a structure 
in which frequently desired states can be easily reached 
from the present state minimize typing and aid rapid inter- 
action. Convenient ways of typing contents of a given 
register in various formats such as symbolic, decimal, or 
octal are also provided. A number of extensions have been 
made on the DDT system. The following is a summary of some 
of these extensions . ^ 

a. Because DDT can accept instructions in symbolic 
assembler-language form, it already nearly 
serves as an "on-line assembler" capable of 
processing the on-line writing and testing of 
small programs. In conventional DDT, the intro- 
duction, in a line of coded input, of a symbol 
not previously defined by the programmer results 
in an error. Edwards and Minsky have added to 
the conventional DDT an "undefined symbol" 
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feature. This feature results in a special 
symbol table entry. These entries are linked 
together and when the symbol is ultimately 
defined by the programmer its previous occur- 
rences are filled in appropriately. 

b. DDT provides an unlimited freedom to patch a 

program. This is accomplished by inserting the 
desired coding in some available space, then 
planting a transfer to this insertion whenever 
desired. Sometimes extensively patched programs 
result. The process of editing or cleaning up 
such a program is long and susceptible to errors. 
At least two attempts have been made to facili- 
tate this editing effort. 

1. One version of such an editing facility 
was developed by Deutsch and Lamson.^^ 

In response to a request by the programmer 
to insert a specified piece of symbolic 
coding, the debugging program performs the 
following : 

(a) Edits the changes into the symbolic 
program stored on the drum. 

(b) Assembles the addition into a "patch 
area" of core and automatically links 
the resulting code to the main program 
by copying instructions and inserting 
transfers . 
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Thus, the patched binary program in core 
is equivalent to the edited symbolic ver- 
sion stored on the drum. At the termination 
of the debugging session the updated symbolic 
program is stored among the programmer's 
files . 

2. Another effort to solve the same problem 
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was developed for the M-460 computer. 

As in the previous approach, the on-line 
programmer presents insertions, deletions, 
or a mixture of both, written in a symbolic 
assembler language, to the debugging pro- 
gram. The debugging program performs the 
following : 

C a ) Symbolic changes are stored along 

with the original symbolic program. 

At the end of the debugging session, 
both are edited and the programmer is 
provided with an updated symbolic file. 

(b) Instead of the patch being made to 
correspond with the programmer's 
changes , the part of the program 
affected by the change is relocated 
appropriately in core. This reloca- 
tion process is possible only because 
the relocation information resulting 
from the assembly of the program is 
collected into a list structure which 
is used by the debugging program when- 
ever a change is called for and it is 
then updated accordingly. The list 
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structure is also used by the relo- 
cation loader. The symbol table 
passed by the assembler to the 
debugging program must also be 
updated each time. 

3. Although this approach may be time-consuming, 
it has several advantages over the "automatic 
patching" approach: 

(a) The patched binary and the edited 
symbolic program may behave differently 
in situations where the location of 
words in core relative to each other 

is important. 

(b) Core may be left in a rather confusing 
state which may require relatively 
frequently reassembly for readability. 

c. In addition to the flexibility in the placement 
and moving of breakpoints provided for in DDT, 
a facility which permits the programmer to make 
the breakpoints conditional has been added to 
some systems. Tests are supplied on-line by the 
programmer and are executed when the breakpoint 
condition is reached to determine if control is 
to be turned over to the programmer. Several 
systems have implemented the use of "canned 
tests." Older versions and a few of the newer 
versions of DDT provide an option whereby the 
programmer can specify a certain number of 
times a point must occur before the break can 
be executed. 
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d. The provision for some form of instruction-by- 
instruction tracing may be desirable. Generally 
such a feature has been omitted in favor of 
breakpoints. Tracing facilities may share 

much of the breakpoint machinery. The program- 
mer should be able to specify a location in his 
program and ask either for control or for a 
printing or both whenever a specified point is 
reached and associated conditions are satisfied. 

e. Another desirable but not widely found feature 
of current on-line debugging systems is extensi- 
bility. Extensibility provides the capability 
in terms of available primitives 

f. An option often found in the DDT system allows 
the programmer to conduct a search between spe- 
cified limits in core for all words matching 

a given word in the bits specified by a given 
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mask. 


4-5. HIGHER-LEVEL LANGUAGE DEBUGGING 
4-6. The LISP System 

The concepts or techniques of on-line assembler 
language debugging are the same as those employed in the 
on-line debugging systems of higher-level languages, the 
systems for higher-level languages are generally better 
developed and more widely used. 



One well-known on-line debugging system developed 
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for higher- level languages is the LISP system. The 

following is a summary of some of the features of various 
49 

LISP systems. 

a. Extensive tracing facilities were originally 
made available to the on-line programmer. This 
feature was later extended and made conditional 
in both the MAC and M-460 LISP systems. 

b. An editing program, not a conventional text 
editor but a program permitting the user to 
modify the list in which LISP functions are 
stored for interpretation, is provided for on 
some LISP systems. The editing feature has 
greatly facilitated the ease in making program 
changes . 

c. Conditional breakpoints which may be inserted 
at any point in a LISP function definition were 
provided for in some LISP systems. Conditional 
breakpoints and tracking make it possible to 
use the full capacity of the LISP language for 
on-line composition of the conditions. This 
permits relatively simple coding of an elaborate 
logical condition for which the counterpart in 
assembly language might be quite complex. Greater 
selectivity may be achieved by suppressing irrel- 
evant tracking and breakpoints through the 
"canning" of a few special predicates used in 
writing conditions. It is possible to find an 
error condition at a breakpoint while running a 
test case, call the editor to make a correction, 
run the program on a simpler test case to verify 
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the correctness of the change, then continue 
with the execution of the original test case 
from the breakpoint. 

d. The MAC and M-460 LISP systems contain both an 
interpreter for LISP functions stored as list 
structures and a compiler for LISP functions in 
symbolic code. These interpreted and compiled 
functions may be intermixed. The interpreter 
makes implementation of debugging facilities 
relatively simple. The insertion of breakpoints 
at arbitrary locations is easily implemented 
by modifying the list structure corresponding 
to the program. 


4-7. The QUIKTRAN System 

QUIKTRAN^ is a debugging system based on the inter- 
pretation of FORTRAN statements. Modifications of the 
FORTRAN program are made freely by inserting and deleting 
statements. The capability of examining and modifying 
variables is provided. A number of modes of tracking are 
available. Extensive run-time diagnostics are made possible 
by the interpretive mode. The system employs a form of 
non-conditional breakpoint capability. The non-conditional 
breakpoint means that a statement can be inserted at any 
point in the program which, when reached, has the effect of 
transferring control to the programmer. 


4-8. The Incremental Compiler 

The concept of an "incremental compiler" is presented 

cr i 

by K. Lock at the California Institute of Technology. 



The basic idea is to compile each program statement separately 
and place the resulting code, together with a copy of the 
symbolic form of the statement, certain pointers, and other 
information, depending on the type of statement, in a con- 
tiguous block of core. These blocks are linked together 
in lists. With the implementation of this concept only 
those portions of a program to be changed need to be recom- 
piled. Insertions and deletions at the statement level 
proceed with modifications of the list. The breakpoint 
capability occurs at statement level since control is 
returned to the monitor between each statement. 
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APPENDIX 


SELECTED DEBUGGING REFERENCES 


The following is a selected list of sources that 
deal in some way with debugging. Abstracts of many appear 
in the Technical Abstract Bulletin Index published by the 
Defense Documentation Center (DDC) , the Research and 
Development Reports abstract journal published by the U. S. 
Department of Commerce, the Scientific and Technical Aero- 
space Reports (STAR) index published by the National 
Aeronautics and Space Administration, and the Computing 
Reviews published by the Association for Computing Machin- 
ery. Key words and phrases have been noted for some of 
the sources. "AD" numbers refer to DDC documents and "S" 
numbers refer to STAR documents. 
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Wiley and Sons, Inc. 1959. 


Randell, B., and Russell, L. J. , ALGOL 60 Implementation , 
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facilities 

Source: ACM Computing Review 


Scott, Theordore G., Computer Programming Techniques , 
Garden City, New York, Doubleday and Company, 
Inc. , 1964 . 
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